Service Routers (SRs) are network devices capable of supporting a variety of different types of services, such as Voice over IP (VoIP) telephony services. As is known in the art, each different type of service may be associated with a different type of application hosted on one or more application servers. To support the different types of services, the SR hosts a server load balancing (SLB) function that dynamically balances the traffic load from the different applications. Particularly, the SLB function distributes the traffic load by forwarding data packets generated by the different applications and received at the SR to multiple servers or processing units.
Conventional SLB functions usually balance the traffic load based on the type of application that generated the traffic. For example, application servers that send Electronic Programming Guides (EPGs) to set top boxes typically encapsulate data in General Packet Radio Service (GPRS) Tunneling Protocol (GTP) packets. Thus, upon receipt of such GTP packets at the SR, the SLB function would forward those packets to a server or processing unit via an appropriate port or interface associated with the forwarding of those types of packets. As another example, a proxy communicating data packets using the HyperText Transfer Protocol (HTTP) requires traffic to be sent and received over port 80/8080. As such, the SLB function would forward received HTTP packets to a server or processing unit via port 80/8080. Regardless of the type of application or service that generates the data packets, however, conventional SLB functions forward traffic to an appropriate processing unit based on the type of application that generated the data packet.
Conventionally, the SLB function utilizes two main approaches to balance the traffic load at the SR. The first approach uses an Access Control List (ACL) to steer traffic to a destination. Particularly, the SLB function first analyzes incoming data packets to determine predefined information, such as a source address for the data packet. The SLB function then accesses the ACL based on the determined source address to identify a corresponding destination address for the data packet. Once the SLB function has determined the appropriate destination address, it forwards the data packet to the destination address in accordance with a predefined rule. However, such a conventional load balancing approach, although useful, is tied to certain, limited information. Particularly, packets may be steered through the network only according source and/or destination address, type of protocol, and/or source and destination port.
In the second approach, the applications that generate the data packets explicitly code a fixed bit field in each data packet with predefined bits that identify the destination. Upon receiving the packet, the SLB function extracts the predefined bits from the fixed bit field for use in selecting, and forwarding the packet to, an appropriate destination processing unit. This approach is also useful, but not without its problems. As stated above, the load balancing rules are different for each type of application that sends data packets to the SR. Therefore, new forwarding path code must be developed and hosted at the SR to be able to support each new application type. Such a practice is resource intensive.
For example, the need to develop new code can complicate the process of porting applications already supported at the SR to and/or from other platforms. Additionally, the forwarding path component at the SR needs to be re-coded for each new application type. However, it is difficult to add new application-specific forwarding code into an existing forwarding plane. Further, any new code could have unwanted interactions with existing load balancing code, or there may be resource issues associated with some applications. It is difficult to optimize the various pieces of forwarding code because the code for each application type is independently developed. Such lack of optimization may lead to the inefficient usage of forwarding plane resources.